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^ (54) Title: QUALITY OR SERVICE PROFILE NEGOTIATION IN A DATA PACKET COMMUNICATIONS SYSTEM 

(57) Abstract: Requesting a Quality of Service for use in a system such as a mobile communication system is performed by using an 
0\ input/output device to receive information from an end-user, and generating a user Quality of Service profile from the information, 
t** The Quality of Service profile is stored in a list of user Quality of Service profiles. When it is time to generate a Requested Quality 
Jp* of Service parameter, one of the Quality of Service profiles is retrieved from the list of Quality of Service profiles, and is used as the 
^2 Requested Quality of Service parameter. Automatically negotiating a Quality of Service involves generating a Requested Quality of 
• — * Service parameter, and transmitting the Requested Quality of Service parameter to a service provider. After receiving a proposed 
^ Quality of Service Negotiated parameter, one or more threshold parameters are retrieved from a stored list of threshold parameters. 

One or more of these are compared with a present parameter state. The proposed Quality of Service negotiated parameter is rejected 
^ if the present parameter state is not wihin a range that is defined by the one or more retrieved threshold parameters. The process is 
J> further facilitated by providing the mobile terminal with a list of Quality of Service profiles that are supported by the PLMN. The 
^ mobile terminal can store these for later use, either manually by the end-user, or automatically by the mobile terniinal. 
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QUALITY OF SERVICE PROFILE NEGOTIATION 
IN A DATA PACKET COMMUNICATIONS SYSTEM 

BACKGROUND 

The present invention relates to packet data communications systems, and 
more particularly to methods and apparatuses that assist the user in negotiating 
with the service provider for a particular quality of service. 

Data packet communications systems are well known. In such systems, 
data (which may represent numerical or any other type of information) is divided 
into discrete units, called "packets". The packets are supplied individually to the 
communications system, which conveys these to the intended recipient's 
communication equipment. On the receiver side of the communication, the 
original data is reconstructed from the received packets, and then supplied to the 
intended recipient. 

Data packet communications systems have traditionally been implemented 
by means of a wire-based connection (e.g., electrical cable or optical fiber). 
However, more recently the principles of data packet communications have been 
applied in wireless applications, thereby providing the user with even greater 
flexibility with respect to the use of such a system. The General Packet Radio 
System (GPRS) is a GSM-based standard that defines one such wireless system. 

Data packet communications systems, including GPRS systems, offer a 
variety of service levels to the user. The particular Quality of Service (QoS) that a 
user experiences may be related to parameter settings that determine such things as 
data throughput, delay, packet connection establishment priority, retention 
priority, transmission medium, channel security, and the like. 

Different users may have different QoS settings, and these are usually 
determined at the time of packet connection establishment. With respect to GPRS 
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sy stems, relevant QoS-related requirements are defined in GSM Specification 
03.60 v.6.2.0 Rel. 1997 . which is hereby incorporated herein by reference. The 
following are defined for GPRS: 



PDF Address 

5 A GPRS subscriber identified by an International Mobile Subscriber 

Identity (IMSI) shall have one or more network layer addresses temporarily and/or 
permanently associated with it that conforms to the standard addressing scheme of 
the respective network layer service used. Network layer addresses are, for 
example, Packet Data Protocol (PDP) addresses, such as: 
10 - Internet Protocol (IP) version 4 addresses; 

IP version 6 addresses; or 
X.121 addresses. 
A GPRS subscription contains the subscription of one or more PDP 
addresses. 



15 PPP Contort 

Each PDP address in a GPRS subscription is described by an individual 
PDP context in the Mobile Station (MS), the Serving GPRS Support Node 
(SGSN), and the Gateway GPRS Support Node (GGSN). Every PDP context 
exists independently in one of two PDP states: ACTIVE and INACTIVE. The 
20 PDP state indicates whether the PDP address is activated for data transfer or not. 

The PDP Context information is described in GSM Specification 03.60 
v 6.2.0 Rel. 1997 section 13.2. 

OqS Profile 

A QoS profile is associated with each PDP context. The QoS profile is 
25 considered to be a single parameter with multiple data transfer attributes. It 

defines the quality of service expected in terms of the following attributes: 
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precedence class; 
delay class; 
reliability class; 
peak throughput class; and 
5 - mean throughput class. 

There are many possible QoS profiles defined by the various combinations 
of the attributes. However, a Public Land Mobile Network (PLMN) is not 
required to support all possible profiles; it may instead support only a limited 
subset of the possible QoS profiles. 

10 OnS Subscribed 

The QoS Subscribed parameter, which is part of the GPRS Subscription 
data stored in the Home Location Register (HLR), denotes a default quality of 
service level associated with a particular subscription. The default is selected if 
the MS does not request a particular QoS profile. It is also included in the PDP 

15 Context information. 

QoS Requested 

The QoS Requested parameter denotes the QoS profile requested by the MS 
at the time of PDP Address activation. This parameter indicates the desired 
profile for a particular data transfer. It is included in the PDP Context 
20 information. 

QoS Negotiated 

The QoS Negotiated parameter denotes the outcome of the negotiation 
between the QoS Requested and the available GPRS resources. It is included in 
the PDP Context information. 
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A conventional solution to the problem of performing QoS profile 
negotiation for a particular data transfer between the MS and the GPRS network is 
described in the GPRS standard (GSM 03.60 version 6.2.0 Release 1997 ). As 
described therein, in order to initiate a data transfer a GPRS MS must first activate 
5 the corresponding PDP Context (and the related PDP Address). At PDP Context 

activation, the MS is allowed to request a specific QoS profile (i.e., QoS 
Requested) for this particular data transfer. The MS requests a value for each of 
the QoS attributes, including the HLR-stored default values (QoS Subscribed). 
For each PDP Address, a different quality of service profile may be 

10 requested. For example, some PDP addresses may be associated with E-mail, 

which can tolerate lengthy response times. Other applications cannot tolerate 
delay and demand a very high level of throughput, interactive applications being 
one example. These different requirements are reflected in the QoS profile. If a 
QoS requirement is beyond the capabilities of a PLMN (i.e., the QoS profiles 

15 which are supported by the PLMN and the available GPRS resources), the PLMN 

negotiates the QoS profile as close as possible to the requested QoS profile. The 
MS either accepts the negotiated QoS profile, or deactivates the PDP context. If 
the MS has accepted the QoS Negotiated, the network shall always attempt to 
provide adequate resources to support the negotiated QoS profiles. 

20 The above-described conventional technique suffers from a number of 

drawbacks: 

First, in order to set up the QoS Requested, the GPRS end-user has to 
decide and identify a desired value for each of the attributes of the QoS profile. In 
some cases this process may be quite complicated (the user has to think and decide 
25 the attribute values of the QoS Requested) and may decrease the usability of the 

QoS negotiation function. The end-user needs a user-friendly tool to assist with 
this task. 

Also, when setting up a QoS Requested, the end-user does not know 
whether the requested QoS is supported by the PLMN (a PLMN may support only 
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a limited subset of the possible QoS profiles), and if so, whether it is available at 
this time. In the event that the QoS Requested is not supported and/or available 
by/from the PLMN, the GPRS end-user has wasted time and effort on the 
identification and the set-up of the desired QoS. For example, the end-user could 
5 instead have simply used the default QoS Subscribed profile. Moreover, the 

request of a QoS that is not supported and/or available by the PLMN increases the 
delays and the processor load in the system because the system has to identify 
which of the supported/available QoS profiles is closer to the requested one; the 
result of this process is the QoS Negotiated parameter. 

10 Furthermore, when the QoS Negotiated is received by the end-user, he or 

she has to decide whether it is acceptable or not. In some cases, this process may 
be quite complicated (the user has to think about the QoS Negotiated and decide 
whether it is good enough and acceptable). This added complication may decrease 
the usability of the QoS negotiation function. The end-user needs a user-friendly 

15 tool to assist him or her. 

Thus, there is the need for improved methods and apparatuses for enabling 
an end-user to more easily and quickly negotiate a quality of service in connection 
with data packet communications . 
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SUMMARY 

20 It is therefore an object of the present invention to provide improved 

techniques relating to QoS negotiation. 

In accordance with one aspect of the present invention, a Requested Quality 
of Service parameter is generated by using an input/output device to receive 
information from an end-user, and generating a user Quality of Service profile 

25 from the information. The Quality of Service profile is then stored in a list of user 

Quality of Service profiles. When the Requested Quality of Service parameter is 
to be generated, one of the Quality of Service profiles is retrieved from the list of 
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Quality of Service profiles, and used as the Requested Quality of Service 
parameter. 

In other aspects of the invention, the information includes a threshold 
parameter that indicates when the generated Quality of Service profile is a 
preferred Quality of Service profile. The threshold parameter may be, but is not 
limited to, any one or combination of the following: a day of the week threshold 
parameter; a day category threshold parameter; a time of day threshold parameter; 
and a type of service threshold parameter. 

In another aspect of the invention, step of using the retrieved Quality of 
Service profile as the Requested Quality of service parameter comprises comparing 
a threshold parameter associated with the retrieved Quality of Service profile with 
a present parameter state; and using the retrieved Quality of Service profile as the 
Requested Quality of service parameter only if the present parameter state is 
within a range that is defined by the threshold parameter associated with the 
retrieved Quality of Service profile. 

In yet another aspect of the invention, if the present parameter state is not 
within a range that is defined by the threshold parameter associated with the 
retrieved Quality of Service profile, then a second one of the Quality of Service 
profiles is retrieved from the list of Quality of Service profiles. The second 
retrieved Quality of Service profile may then be used as the Requested Quality of 
Service parameter. 

In still another aspect of the invention, one or more supported Quality of 
Service profiles are retrieved from a list of supported Quality of Service profiles. 
In such embodiments, the step of using the retrieved Quality of Service profile as 
the Requested Quality of service parameter comprises: comparing the retrieved 
Quality of Service profile with at least one of the retrieved one or more supported 
Quality of Service profiles; and using the retrieved Quality of Service profile as 
the Requested Quality of service parameter only if the retrieved Quality of Service 
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profile matches at least one of the retrieved one or more supported Quality of 
Service profiles. 

In yet another aspect of the invention, a Quality of Service Negotiated 
parameter is automatically negotiated by generating a Requested Quality of Service 
parameter, and transmitting the Requested Quality of Service parameter to a 
service provider. A proposed Quality of Service Negotiated parameter is then 
received. One or more threshold parameters are also retrieved from a stored list 
of threshold parameters. These are compared with a present parameter state. The 
proposed Quality of Service negotiated parameter is then rejected if the present 
parameter state is not within a range that is defined by the one or more retrieved 
threshold parameters. 

In other aspects of the invention, the one or more threshold parameters may 
include, but are not limited to, any one or combination of the following: a day of 
the week threshold parameter; a day category threshold parameter; a time of day 
threshold parameter; a type of service threshold parameter; and an importance of 
attribute threshold parameter. 

In yet another aspect of the invention, a mobile terminal is supplied with 
information about Quality of Service profiles supported by a PLMN. This 
includes transmitting a list of supported Quality of Service profiles from the 
PLMN to the mobile terminal; and in the mobile terminal, storing the list of 
supported Quality of Service profiles in a memory device. 

In still another aspect of the invention, a revised list of supported Quality 
of Service profiles is generated in the PLMN. In such instances, the transmitting 
step may be performed in response to the revised list of supported Quality of 
Service profiles being generated. 

In yet another aspect of the invention, the mobile terminal is a roaming 
terminal in the service area of the PLMN; and the step of transmitting the list of 
supported Quality of Service profiles from the PLMN to the mobile terminal is 
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performed in response to the mobile station registering for the first time in the 
PLMN. 

In still another aspect of the invention, the step of transmitting the list of 
supported Quality of Service profiles from the PLMN to the mobile terminal 
comprises using a point-to-point message between the PLMN and the mobile 
terminal to transmit the list of supported Quality of Service profiles from the 
PLMN to the mobile terminal. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The objects and advantages of the invention will be understood by reading 
the following detailed description in conjunction with the drawings in which: 

FIG. 1 is a block diagram of a mobile station and a public land mobile 
network embodying the various aspects of the invention; and 

FIG. 2 is a flow chart depicting the operation of a QoS negotiator, in 
accordance with an aspect of the invention. 

DETAILED DESCRIPTION 

The various features of the invention will now be described with respect to 
the figures, in which like parts are identified with the same reference characters. 

In one aspect of the invention, the end-user of a Mobile Station (MS) is 
provided with a tool that facilitates the creation of one or more desired QoS 
profiles, each being tailored for use under particular conditions (e.g., present day 
of the week, time of day, type of service). The QoS profdes may be stored within 
the MS. 

In another aspect of the invention, the MS may store a list of QoS 
configurations that are available in the service area of a PLMN. This list may be 
useful under several circumstances. First, it may be useful to the end-user for use 
as a reference when the user is creating and/or modifying his QoS profiles. 
Moreover, the list of available QoS configurations provides the MS and/or end- 
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user with the information necessary to avoid unnecessarily setting up a QoS 
Requested parameter that requests a QoS that is not supported or available from 
the PLMN. In another aspect of the invention, whenever the operator of the 
PLMN updates the list, the system sends a system information broadcast message 
to inform the MSs of these updates. 

In yet another aspect of the invention, the MS is provided with an 
automated QoS negotiator. The automated QoS negotiator uses information about 
the PLMN's available QoS configurations, the end-user's QoS profiles, and 
relevant parameters (e.g., present day of the week, time of day, type of service) to 
automatically generate a QoS Requested parameter that is suitable for the existing 
conditions, and to automatically decide whether the QoS Negotiated proposed by 
the system is acceptable by the end-user. 

These and other aspects of the invention will now be described in greater 
detail in connection with a number of exemplary embodiments. To facilitate an 
understanding of the invention, many aspects of the invention are described in 
terms of sequences of actions to be performed by elements of a computer or other 
type of processor. It will be recognized that in each of the embodiments, the 
various actions could be performed by specialized circuits (e.g., discrete logic 
gates interconnected to perform a specialized function), by program instructions 
being executed by one or more processors, or by a combination of both. 
Moreover, the invention can additionally be considered to be embodied entirely 
within any form of computer readable storage medium having stored therein an 
appropriate set of computer instructions that would cause a processor to carry out 
the techniques described herein. Thus, the various aspects of the invention may be 
embodied in many different forms, and all such forms are contemplated to be 
within the scope of the invention. For each of the various aspects of the invention, 
any such form of embodiment may be referred to herein as "logic configured to" 
perform a described action. 
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Referring now to FIG. 1, a block diagram of an MS 101 and PLMN 103 
embodying the various aspects of the invention is shown. The MS 101 
communicates with a PLMN 103 by means of radio signals 105 in accordance with 
any of a number of well known radio communication standards, such as GPRS. 
5 This is performed by means of transceiver circuitry 107, which is well-known in 

the art. Within the MS 101, the transceiver circuitry 107 exchanges signals with a 
number of components, including end-user input/output components 109 
(henceforth referred to as "I/O components 109") which may include, but are not 
limited to, any or all of the following: a loudspeaker, a display device and a 

10 keyboard device (not shown). 

In accordance with one aspect of the invention, the MS 101 further includes 
a setup tool 111 that is coupled to the I/O components 109. The setup tool 111 
provides information to the end-user (via one or more output elements of the I/O 
components 109) that enables the user to more easily decide upon and enter (via 

15 one or more input elements of the I/O components 109) desired values for one or 

more QoS profiles. The user may wish to establish more than one QoS profile, 
with each one being particularly adapted for use under a particular set of 
conditions. Such conditions, or threshold parameters, may include, but are not 
limited to, such considerations as day of the week, day category (e.g., to permit 

20 QoS differentiation on the basis of weekdays versus weekends), time of day, type 

of service (e.g., E-mail, interactive data services), and the like. 

To allow the setup tool 111 to perform these functions, the MS 101 further 
includes one or more memory components for storing a list of user QoS profiles 
113 and various threshold values 115. The setup tool 111 is coupled to these one 

25 or more memory components to enable it to store new user QoS profiles and 

threshold values and also to retrieve and modify (including deleting) existing ones. 
Existing user QoS profiles and threshold values may be supplied to the end-user 
(via the I/O components 109) to ease the task of creating one or more new ones, or 
modifying existing ones. 
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In another aspect of the invention, the setup tool 111 may further have 
access to a list of supported QoS profiles 117, which may also be stored in the one 
or more memory components mentioned above, or in another memory component. 
The MS 101 may be supplied with an initial list of supported QoS profiles 117 at 
the time that the end-user subscribes to a specific service. However, to 
accommodate the fact that these lists do not remain static, each time the operator 
updates the list (e.g., adds, removes, or updates a supported QoS configuration), 
the PLMN 103 sends a system information broadcast message to inform the MSs 
101 of any updates in the QoS list. This system information broadcast message is 
supplied to a component within the MS 101 referred to herein as the supported 
QoS profile updater 119, which interprets the broadcast message and modifies the 
list of supported QoS profiles 117. 

This facility may further be made available to roaming MSs as well. When 
a roaming MS 101 is registered for the first time in the operator's PLMN 103, the 
PLMN 103 can transmit the list of supported QoS configurations to it with a point- 
to-point message, which can also be processed and acted upon by the supported 
QoS profile updater 119. 

The setup tool 111 may supply the list of supported QoS profiles 117 to the 
end-user via the I/O components 109 so that whenever the end-user wants to 
negotiate the QoS for a specific data transfer, he may use this list as a basis for 
deciding which of the available QoS profiles (stored as the list of user QoS profiles 
113) will be used as the QoS Requested. This greatly increases the efficiency of 
the process because a user can easily avoid selecting a QoS profile that specifies a 
level of QoS that he knows will not be supported by the PLMN 103. 

In yet another aspect of the invention, the negotiation of a quality of service 
can be automated. For this purpose, the MS 101 may further be equipped with a 
QoS negotiator 121 that is coupled to the transceiver circuitry 107, the list of user 
QoS profiles 113, the list of threshold parameters 115, and the list of supported 
QoS profiles 117. FIG. 2 is a flowchart depicting the operation of the QoS 



WO 01/65779 PCT/EP01/02201 



-12- 

negotiator 121. When the MS 101 initiates the PDP Context Activation, the QoS 
negotiator 121 list of user QoS profiles, and selects one. This selection may take 
into account none, some or all of the following: the threshold parameters 115 
coupled with present threshold values; and the list of supported QoS profiles 117. 
5 The selected user QoS profile is then included in the QoS Requested field of the 

PDP Context Activation message (step 201). The PDP Context Activation 
message is then transmitted to the PLMN 103 (step 203). 

The MS 101 then receives a response from the PLMN 103 in the form of a 
proposed QoS Negotiated parameter (step 205). In response, the QoS negotiator 

10 121 decides whether the proposed QoS Negotiated parameter is acceptable. Of 

course, this decision may simply be made on the basis of whether the proposed 
QoS Negotiated parameter matches the QoS Requested parameter. However, if 
there is some difference between the two, it may still be acceptable for the end- 
user's purposes. Thus, the decision whether the proposed QoS Negotiated 

15 parameter is acceptable may be further based on the list of threshold parameters 

115 (step 207). For example, these threshold parameters may associate a binary 
value with each QoS attribute, with the binary value indicating whether the 
proposed QoS Negotiated attribute must exactly match the requested one, or 
whether alternatively any proposed value would be acceptable. If the proposed 

20 attribute does not match, then the QoS Negotiated parameter should be rejected. 

Alternatively, a threshold parameter may define a range of attribute values that 
would be acceptable. The threshold in this case may specify the acceptable (or 
unacceptable) values themselves, or it may indicate an amount of deviation from a 
requested attribute value (e.g., requested attribute +/- 1). In this specification, the 

25 term "range" is used to define the acceptable (or unacceptable) attribute values, 

regardless of whether that range is a single acceptable (or unacceptable) value 
(e.g., in the case of a binary threshold parameter) or whether it is a number of 
acceptable (or unacceptable) values. 
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If the proposed QoS Negotiated parameter is within certain threshold 
boundaries, as defined by the list of threshold parameters 115, then the proposed 
QoS Negotiated parameter may be acceptable. Threshold parameters may include, 
but are not limited to, day of the week, day category (e.g., to permit QoS 
differentiation on the basis of weekdays versus weekends), time of day, type of 
service (e.g., E-mail, interactive data services), and the importance of a QoS 
attribute (e.g., associate weights to each of the possible QoS attributes). 

The QoS negotiator 121 then generates a suitable response and transmits 
this to the PLMN 103 (step 209). The response may either accept or reject the 
PLMN's proposal. 

The invention provides a number of advantages. The setup tool 111 
simplifies and speeds up the user's ability to establish one or more QoS Requested 
profiles. QoS negotiator 121 further simplifies the process by automating the QoS 
negotiation procedure, taking into account the supported QoS profiles, as well as 
whether the QoS Negotiated that is proposed by the PLMN falls within acceptable 
limits (as set by the threshold parameters 115). 

The invention has been described with reference to a particular 
embodiment. However, it will be readily apparent to those skilled in the art that it 
is possible to embody the invention in specific forms other than those of the 
preferred embodiment described above. This may be done without departing from 
the spirit of the invention. 

For example, the above-described embodiments utilize parameters as 
specified in accordance with the GPRS standards. However, this is not an 
essential feature of the invention, which can easily be adapted for use with Quality 
of Service parameters as defined in accordance with other standards. 

Thus, the preferred embodiment is merely illustrative and should not be 
considered restrictive in any way. The scope of the invention is given by the 
appended claims, rather than the preceding description, and all variations and 
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equivalents which fall within the range of the claims are intended to be embraced 
therein. 
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WHAT IS CLAIMED IS: 

1 . A method of generating a Requested Quality of Service parameter, 
comprising: 

using an input/output device to receive information from an end-user; 
5 generating a user Quality of Service profile from the information; 

storing the Quality of Service profile in a list of user Quality of Service 
profiles; 

retrieving one of the Quality of Service profiles from the list of Quality of 
Service profiles; and 

10 using the retrieved Quality of Service profile as the Requested Quality of 

Service parameter. 

2. The method of claim 1 , wherein the information includes a threshold 
parameter that indicates when the generated Quality of Service profile is a 
preferred Quality of Service profile. 

15 3. The method of claim 2, wherein the threshold parameter is a day of the 

week threshold parameter. 

4. The method of claim 2, wherein the threshold parameter is a day category 
threshold parameter. 

5. The method of claim 2, wherein the threshold parameter is a time of day 
20 threshold parameter. 

6. The method of claim 2, wherein the threshold parameter is a type of service 
threshold parameter. 
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7. The method of claim 1, wherein the step of using the retrieved Quality of 
Service profile as the Requested Quality of service parameter comprises: 

comparing a threshold parameter associated with the retrieved Quality of 
Service profile with a present parameter state; and 

using the retrieved Quality of Service profile as the Requested Quality of 
service parameter only if the present parameter state is within a range that is 
defined by the threshold parameter associated with the retrieved Quality of Service 
profile. 

8. The method of claim 7, further comprising: 

if the present parameter state is not within a range that is defined by the 
threshold parameter associated with the retrieved Quality of Service profile, then 
retrieving a second one of the Quality of Service profiles from the list of Quality 
of Service profiles; and 

using the second retrieved Quality of Service profile as the Requested 
Quality of Service parameter. 

9. The method of claim 1, Anther comprising: 

retrieving one or more supported Quality of Service profiles from a list of 
supported Quality of Service profiles, 

and wherein the step of using the retrieved Quality of Service profile as the 
Requested Quality of service parameter comprises: 

comparing the retrieved Quality of Service profile with at least one of the 
retrieved one or more supported Quality of Service profiles; and 

using the retrieved Quality of Service profile as the Requested Quality of 
service parameter only if the retrieved Quality of Service profile matches at least 
one of the retrieved one or more supported Quality of Service profiles. 
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10. A method of automatically negotiating a Quality of Service Negotiated 
parameter, comprising: 

generating a Requested Quality of Service parameter; 
transmitting the Requested Quality of Service parameter to a service 
5 provider; 

receiving a proposed Quality of Service Negotiated parameter; 
retrieving one or more threshold parameters from a stored list of threshold 
parameters; 

comparing the one or more retrieved threshold parameters with a present 
10 parameter state; and 

rejecting the proposed Quality of Service negotiated parameter if the 
present parameter state is not within a range that is defined by the one or more 
retrieved threshold parameters. 

11. The method of claim 10, wherein the one or more threshold parameters 
15 comprise a day of week threshold parameter. 

12. The method of claim 10, wherein the one or more threshold parameters 
comprise a day category threshold parameter. 

13. The method of claim 10, wherein the one or more threshold parameters 
comprise a time of day threshold parameter. 

20 14. The method of claim 10, wherein the one or more threshold parameters 

comprise a type of service threshold parameter. 



15. The method of claim 10, wherein the one or more threshold parameters 
comprise an importance of attribute threshold parameter. 
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16. A method of supplying a mobile terminal with information about Quality of 
Service profiles supported by a PLMN, comprising: 

transmitting a list of supported Quality of Service profiles from the PLMN 
to the mobile terminal; and 

in the mobile terminal, storing the list of supported Quality of Service 
profiles in a memory device. 

17. The method of claim 16, further comprising: 

generating a revised list of supported Quality of Service profiles in the 
PLMN, 

and wherein the transmitting step is performed in response to the revised 
list of supported Quality of Service profiles being generated. 

18. The method of claim 16, wherein: 

the mobile terminal is a roaming terminal in the service area of the PLMN; 

and 

the step of transmitting the list of supported Quality of Service profiles 
from the PLMN to the mobile terminal is performed in response to the mobile 
station registering for the first time in the PLMN. 

19. The method of claim 18, wherein the step of transmitting the list of 
supported Quality of Service profiles from the PLMN to the mobile terminal 
comprises using a point-to-point message between the PLMN and the mobile 
terminal to transmit the list of supported Quality of Service profiles from the 
PLMN to the mobile terminal. 

20. An apparatus for generating a Requested Quality of Service parameter, 
comprising: 
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logic configured to use an input/output device to receive information from 
an end-user; 

logic configured to generate a user Quality of Service profile from the 
information; 

5 logic configured to store the Quality of Service profile in a list of user 

Quality of Service profiles; 

logic configured to retrieve one of the Quality of Service profiles from the 
list of Quality of Service profiles; and 

logic configured to use the retrieved Quality of Service profile as the 
10 Requested Quality of Service parameter. 

21. The apparatus of claim 20, wherein the information includes a threshold 
parameter that indicates when the generated Quality of Service profile is a 
preferred Quality of Service profile. 

22. The apparatus of claim 21, wherein the threshold parameter is a day of the 
15 week threshold parameter. 

23. The apparatus of claim 21, wherein the threshold parameter is a day 
category threshold parameter. 

24. The apparatus of claim 2 1 , wherein the threshold parameter is a time of day 
threshold parameter. 

20 25. The apparatus of claim 21, wherein the threshold parameter is a type of 

service threshold parameter. 
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26. The apparatus of claim 20, wherein the logic configured to use the 
retrieved Quality of Service profile as the Requested Quality of service parameter 
comprises: 

logic configured to compare a threshold parameter associated with the 
retrieved Quality of Service profile with a present parameter state; and 

logic configured to use the retrieved Quality of Service profile as the 
Requested Quality of service parameter only if the present parameter state is 
within a range that is defined by the threshold parameter associated with the 
retrieved Quality of Service profile. 

27. The apparatus of claim 26, further comprising: 

logic configured to retrieve a second one of the Quality of Service profiles 
from the list of Quality of Service profiles if the present parameter state is not 
within a range that is defined by the threshold parameter associated with the 
retrieved Quality of Service profile; and 

logic configured to use the second retrieved Quality of Service profile as 
the Requested Quality of Service parameter. 

28. The apparatus of claim 20, further comprising: 

logic configured to retrieve one or more supported Quality of Service 
profiles from a list of supported Quality of Service profiles, 

and wherein the logic configured to use the retrieved Quality of Service 
profile as the Requested Quality of service parameter comprises: 

logic configured to compare the retrieved Quality of Service profile with at 
least one of the retrieved one or more supported Quality of Service profiles; and 

logic configured to use the retrieved Quality of Service profile as the 
Requested Quality of service parameter only if the retrieved -Quality of Service 
profile matches at least one of the retrieved one or more supported Quality of 
Service profiles. 
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29. An apparatus for automatically negotiating a Quality of Service Negotiated 
parameter, comprising: 

logic configured to generate a Requested Quality of Service parameter; 

logic configured to transmit the Requested Quality of Service parameter to 
5 a service provider; 

logic configured to receive a proposed Quality of Service Negotiated 
parameter; 

logic configured to retrieve one or more threshold parameters from a stored 
list of threshold parameters; 
10 logic configured to compare the one or more retrieved threshold parameters 

with a present parameter state; and 

logic configured to reject the proposed Quality of Service negotiated 
parameter if the present parameter state is not within a range that is defined by the 
one or more retrieved threshold parameters. 

15 30. The apparatus of claim 29, wherein the one or more threshold parameters 

comprise a day of week threshold parameter. 

31. The apparatus of claim 29, wherein the one or more threshold parameters 
comprise a day category threshold parameter. 

32. The apparatus of claim 29, wherein the one or more threshold parameters 
20 comprise a time of day threshold parameter. 

33. The apparatus of claim 29, wherein the one or more threshold parameters 
comprise a type of service threshold parameter. 

34. The apparatus of claim 29, wherein the one or more threshold parameters 
comprise an importance of attribute threshold parameter. 
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35. An apparatus for supplying a mobile terminal with information about 
Quality of Service profiles supported by a PLMN, comprising: 

logic configured to transmit a list of supported Quality of Service profiles 
from the PLMN to the mobile terminal; and 

in the mobile terminal, logic configured to store the list of supported 
Quality of Service profiles in a memory device. 

36. The apparatus of claim 35, further comprising: 

logic configured to generate a revised list of supported Quality of Service 
profiles in the PLMN, 

and wherein the logic configured to transmit operates in response to the 
revised list of supported Quality of Service profiles being generated. 

37. The apparatus of claim 35, wherein: 

the mobile terminal is a roaming terminal in the service area of the PLMN; 

and 

the logic configured to transmit the list of supported Quality of Service 
profiles from the PLMN to the mobile terminal operates in response to the mobile 
station registering for the first time in the PLMN. 

38. The apparatus of claim 37, wherein the logic configured to transmit the list 
of supported Quality of Service profiles from the PLMN to the mobile terminal 
comprises logic configured to use a point-to-point message between the PLMN and 
the mobile terminal to transmit the list of supported Quality of Service profiles 
from the PLMN to the mobile terminal. 



WO 01/65779 



PCT/EP01/02201 



1/2 



8 




o 



O 

l 

CO 
Hi 

£ 
o 



qUJ 

Ui == 
h- U. m 
DCOh 
OC< 
CQ-Q 

SrCoSr 
3 o -J 
CO o 



7 



o 



UJ fc 

§§ 

UJ CL 

z 



a: 
o 

o 

HI 



o 

g 

CL 

ts 

CO 



Q UJ 
Ui -J 

LL •== 



CO , 



7 



27 



)LD | 


ERS 


SH( 


tu 


Ui 




0£ 




X 






cl 



a: co 
co =i 
i. Q 



*7 



g 

LL 



2/2 



PCT/EP01/02201 



GENERATE REQUESTED QoS 
PARM BASED ON LIST OF 
USER QoS PROFILES, 
THRESHOLD PARMS, LIST OF 
SUPPORTED QoS PROFILES, 
AND PRESENT THRESHOLD 
VALUES 







TRANSMIT QoS REQUESTED 
PARM TO PLMN 






RECEIVE PROPOSED QoS 
NEGOTIATED PARM FROM 
PLMN 







DECIDE WHETHER 
PROPOSED QoS 
NEGOTIATED PARM IS 
ACCEPTABLE, BASED ON 

STORED LIST OF 
THRESHOLD PARAMETERS 







RESPOND TO PLMN'S 
PROPOSAL 



201 



203 



205 



207 



209 



( E "° ) 



FIG. 2 



